Note that any 4.x deployment that has messages currently sitting in the processing queue should drain that queue before deploying this fix. move_expired_message.lua preserves raw bytes verbatim when rescuing messages, so alphabetical-order bytes written by an unpatched 4.x instance are never corrected by the rescue path — the ZSCORE miss will recur on every re-delivery, creating the same infinite loop as the original bug, just in reverse.

Can we add this as a prop?

A property based solution seems to get rather messy. I'll try to implement a more robust solution (e.g. making the processing-queue lookups in move_message_zset.lua, move_message_list.lua, and ack using an ID-based fallback).

A property based solution seems to get rather messy. I'll try to implement a more robust solution (e.g. making the processing-queue lookups in move_message_zset.lua, move_message_list.lua, and ack using an ID-based fallback).

This would be quick change right? We can add a property rqueue.serialization.property.order=ALPHABETICALLY|DEFAULT.

DEFAULT (declaration order, matching Jackson 2.x / RQueue 3.x) as the out-of-the-box value is intended? Meaning projects already using 4.x are required to explicitly set ALPHABETICALLY.

Maybe using ALPHABETICALLY as the default value, naming the old declaration order LEGACY and adding documentation to the migration guide is a more future proof approach here.

DEFAULT (declaration order, matching Jackson 2.x / RQueue 3.x) as the out-of-the-box value is intended? Meaning projects already using 4.x are required to explicitly set ALPHABETICALLY.

Maybe using ALPHABETICALLY as the default value, naming the old declaration order LEGACY and adding documentation to the migration guide is a more future proof approach here.

Yeah this make sense, Also we can take a approach used by Lombok. Serialization format jackson2.x or jackson3+. Both of these would work, but adding legacy does not tell us why this is called legacy.

Both of these would work, but adding legacy does not tell us why this is called legacy.

You're right, naming should be consistent and describe the actual behaviour.

Added rqueue.serialization.property.order=ALPHABETICAL|DECLARATION to control JSON property ordering. ALPHABETICAL (Jackson 3.x native) is the default for new 4.x deployments. Set DECLARATION when upgrading from 3.x with messages still present in Redis queues.